04. 确定你的任务

你的任务

假设你正在使用某个第三方库构建一个项目。如果在使用此第三方库时遇到 bug 或拼写错误，该怎么办？虽然你有能力修复它，但你没有直接访问原库进行修改的权限。不过这不是问题，因为你知道 fork 其他开发者的仓库可以将其复制到你的帐户，使你可以全权对它执行 git pull 和 git push ！

但是，当你获得了其他开发者项目的副本，并拥有完全访问权限后，你应该做什么？我们将在下节课学习这一部分，但是如果你 fork 了一个项目，并且你的 fork 中包含原项目所没有的代码，则可以通过向原项目的维护者发送一个请求，将你的代码更改包含在其中，请求维护者将这些更改拉取到原项目中。这种请求称为“拉取请求”（Pull Request）。再次说明，我们将在下一课中介绍发送和使用“Pull Request”。所以，现在你知道如何将你的代码加入到原项目中的方法，并且你想帮助解决这个拼写/代码错误。那么你有任务在身啦！但是，你如何以原项目维护者能接受的方式实际对项目做出贡献，并使他最终合并你的更改？记住，你要做的第一件事，是在项目中寻找一个名为 CONTRIBUTING.md 的文件。

CONTRIBUTING.md 文件

CONTRIBUTING.md 文件的名称特别采用全大写，以方便查找。你可能会从它的名称猜到文件的用途，此文件列出了你要为项目做出贡献时所应遵循的信息。在开始任何开发工作之前，应先找到此文件。
我们来看看 Lighthouse 项目的 CONTRIBUTING 文件：

你可以看到文件的顶行说：

欢迎你提供帮助！本文档介绍了如何成为贡献者并向项目提交代码。

本文件有两个主要部分：

• "For Contributors" 面向贡献者的部分
• "For Maintainers" 面向维护者的部分

每部分都有各自的小节，指导读者如何加入此项目和做出贡献。

我们来看看签署贡献者许可证的小节。以下是在制作此课程时此小节的显示内容：

可以看到，要为此项目做出贡献，你需要签署 Google 的“贡献者许可协议”。

可以看到，此贡献者文件中包含大量信息。所以当你想对一个项目做出贡献时，一定要查阅 CONTRIBUTING.md 文件。

GitHub Issues

如果你的代码更改只是修改简单的拼写错误，那么你可以直接进行更改。但如果你要做涉及大量文件的重大修改，则你可能要在开始之前，先获得项目维护者的批准。你肯定不想花几个小时更改项目，最后却发现别人正在做同样的事情。到头来，花费了大量时间和精力做了重复工作。在 CONTRIBUTING.md 文件中，它解释了应该 如何 规范书写代码，以及你做出贡献的方式，但你如何知道应该贡献 什么 呢？你应该直接与项目维护人员交谈。GitHub 有一个非常赞的页面，使你能以公开的方式向项目维护者提问，让每个人都能看到项目的动态。

这是 GitHub 的 Issues 界面：

注意，这里说的"Issues（问题）"并不代表实际存在错误，它可以是需要对项目进行的任何改变。GitHub 的问题跟踪器相当高级。每个问题都可以：

• 应用一个或多个标签
• 被分配给个人
• 确定一个里程碑（例如问题将由下一个主要版本解决）

但问题跟踪器最重要的一个方面在于，每个问题都可以有自己的评论区，使开发者围绕这个问题展开对话。

查看这个有很多评论的 问题 ：

Issue 的另一个很棒的功能在于：

• 你可以订阅某个 Issue ，这样你便会获得新评论和代码更改的通知
• 你可以就具体变更与项目维护者持续交流

在向某个文件贡献任何内容之前，请查看 CONTRIBUTING.md 中的说明。然后查看项目的 Issue，看是否有哪些与你要贡献的内容类似。如果有，则订阅该 Issue 并阅读现有的对话，看你是否可以提供帮助。如果你查看了 Issues 列表，没有看到与你要做的事情类似的内容，那么你可以创建自己的新 Issue。在 GitHub 问题界面的每个页面上，都能找到“New Issue（新建问题）”按钮：

点击该按钮可以创建新问题

New Issue 页

新建问题页好的一点在于，如果项目有 CONTRIBUTING.md 文件，它会在页面顶部显示一个提醒，要求你查看有关如何为项目做贡献的准则。点击"guidelines for contributing"链接，可以转至 CONTRIBUTING.md 文件。

GitHub 问题页面支持 Markdown，所以当你创建了自己的问题后，可以使用 Markdown 编排格式，并通过包含链接、图像、项目符号列表和代码块按照你想要的方式进行编写。

💡 学习 Markdown！ 💡

从 README 文件，到新建问题页面及评论，Markdown 都极其重要！如果你不熟悉 Markdown，请查看我们的[编写 README] 课程 ( https://www.udacity.com/course/writing-readmes--ud777)，我们将会讲解关于 Markdown 的所有知识。该课程十分简短，有什么理由不花上一小时时间学习这项强大的技能！

与编写描述性的提交说明一样，你在创建问题时，要给它一个信息丰富的标题，简要说明你想要做的事情。然后，在评论部分，提供大量关于此更改的详细信息，可以是你为什么认为此更改有必要，也可以是它如何改进项目。

通常情况下，项目的维护者都有全职工作，只在闲暇时间研究项目，因此，在你急着进行修改前，请给他们一些时间来回答你的问题。一旦项目维护者给予批准，你便可以开始应用想要贡献给项目的更改了。

特性分支

组织你想贡献给项目的一系列 commit 或更改的最佳方法，是 将它们全部放在一个特性分支上 。我说的 特性分支 是什么意思呢？与主分支不同，主分支是保存整个项目的所有 commit 的默认分支，而特性分支仅保存单个概念或单个更改区域的 commit 。

例如，如果登录某个网站的登录表单有问题，则解决此特定问题的分支名称可以叫做：

• login
• login-bug
• signup-bug
• login-form-bug
• 等等。

有很多名称可以用作特性分支的名称。你只需为分支提供一个清晰的描述性名称，以便在列出所有分支时，你可以立即根据名称确定要在分支中做哪些更改。

要记住的一点是，有时项目会对特性分支的命名有特定要求。例如，如果一个分支将要解决错误修复，那么许多项目会要求添加一个 bugfix- 前缀。回到我们处理登录表单错误的分支，它得被命名为 bugfix-login-form 。所以一定要阅读 CONTRIBUTING.md 文件，确定项目是否对特性分支的命名提供了特别说明。

最佳实践

编写描述性的提交说明

在谈论如何命名分支，以清晰描述分支会包含 哪些 更改的同时，我想另外提醒一下如何编写清晰、描述性的提交说明。你的分支名称和提交说明描述得越清楚，项目维护者用于询问你的代码的用途，或者自己去深入了解代码的时间就越少。项目维护者需要做的工作越少，将你的更改纳入项目的速度就越快。

创建短小而明确的 commit

这一点我们之前已经强调了很多次，请确保在对项目 commit 更改时，使用短小的 commit。不要进行大量 commit，记录 10 多个文件和数百行代码的更改。最好频繁多次地进行小的 commit，只记录很少数量的文件和代码更改。

你可以这样想：如果开发者不喜欢你的大量 commit 中的 一部分 更改，他们不可能说"我赞成 commit A，只是不赞成改变边栏背景颜色的那部分。" 一个 commit 不能分解成几个小块，所以确保你的 commit 足够小，每个只集中解决一个更改。这样，维护者可以说“我赞成 commit A、B、C、D 和 F，但不赞成 commit E。

更新 README

最后，如果你添加的任何代码更改会使项目发生极大的变化，则应更新 README 文件以向其他人说明此更改。

小结

在开始任何工作之前，确保阅读项目的 CONTRIBUTING.md 文件。

接下来，查看项目的 GitHub 问题

• 查看现有的问题，看是否有哪些内容类似于你想贡献的更改
• 如有必要，创建一个新的 Issue
• 与项目维护者交流你想要做出的更改

当开始开发后，将所有工作 commit 到特性分支上：

• 不要在主分支上工作
• 确保给特性分支赋予一个清晰、描述性的名称

以及编写 commit 的一般最佳实践

• 频繁少量 commit
• 使用清晰、具有描述性的提交说明
• 必要情况下，更新 README 文件